The OpenFlow Switching Protocol is defined by the OpenFlow Switch Consortium in the OpenFlow Switch Specification, and is intended as a way for researchers to run experimental protocols in their networks. FIG. 1 depicts a representation of an OpenFlow switch 10, which is based on an Ethernet switch, with an internal flow table 12 (also known as a forwarding table 12) that performs packet lookup and forwarding, and a secure channel 14 to an external controller 16. The controller 16 manages the OpenFlow switch 10 over the secure channel 12 using the OpenFlow protocol.
A flow table 12 contains a set of flow entries 18, one of which is depicted in FIG. 2. Each flow entry 18 comprises a set of flow rules 20 used to match against packets (i.e., header values that can be used to match against packet headers), a set of zero or more actions 22 to apply to matching packets, and activity counters 24. All packets processed by the OpenFlow switch 10 are compared against the flow table rules 20. If a matching entry 18 is found, any actions 22 for that entry 18 are performed on the packet (e.g., an action might be to forward a packet on a specified port). If no match is found, the packet is forwarded to the controller 16 over the secure channel 14. The controller 16 is responsible for determining how to handle packets that do not have valid flow entries 18, and manages the flow table 12 by adding and removing flow entries 18.
In the example depicted in FIG. 2, the flow entry rules 20 include fields from several layers of the protocol stack, such as the Ethernet MAC addresses, IP address, IP protocol, TCP/UDP port numbers as well as the incoming port number. Each entry must contain either a specific value, or a wildcard “ANY” entry, which matches any value. If the switch 10 supports subnet masks on the IP source and/or destination fields, these can more precisely specify matches.
Each flow entry 18 is also associated with zero or more actions 22 that dictate how the OpenFlow switch 10 handles packets that match the rules 20 of the flow entry 18. For example, these actions 22 can include dropping a packet, forwarding a packet on an outgoing port, forward the packet on the incoming port, forwarding a packet on all outgoing ports, forwarding the packer to the controller, and the like. If no actions 22 are present in a flow entry 18, then a packet matching that entry 18 is dropped. A switch 10 is not required to support all action types, as some actions 22 are required and others are optional. When connecting to the controller 16, a switch 10 indicates which of the optional actions 22 it supports.
The secure channel 14 is the interface that connects each OpenFlow switch 10 to a controller 16. Through this interface, the controller 16 configures and manages the switch 10, receives events from the switch 10, and sends packets out from the switch 10. All messages set over the secure channel 14 must be formatted according to the OpenFlow protocol defined in the OpenFlow Switch Specification. The OpenFlow protocol supports three message types: controller-to-switch messages, asynchronous messages, and symmetric messages, each of which has multiple sub-types.
Controller-to-switch messages are initiated by the controller 16 and used to directly manage or inspect the state of the switch 10. Controller-to-switch messages may or may not require a response from the switch 10. Controller-to-switch messages include Features messages, Configuration messages, Modify-State messages, Read-State messages, Send-Packet messages, and Barrier messages.
Features messages communicate supported features between the switch 10 and the controller 16. Upon Transport Layer Security (TLS) session establishment, the controller 16 sends a Features Request message to the switch 10. The switch 10 must reply with a Features Reply that species the capabilities supported by the switch 10.
Configuration messages configure the switch 10. The controller 16 sets and queries configuration parameters in the switch 10. The switch 10 only responds to a query from the controller 16.
Modify-State messages are sent by the controller 16 to manage state on the switches 10. Their primary purpose is to add/delete and modify flows in the flow tables 12 and to set switch port properties.
Read-State messages are used by the controller 16 to collect statistics from the switch's flow-tables 12, ports and the individual flow entries 18.
Send-Packet messages are used by the controller 16 to send packets out of a specified port on the switch 10.
Barrier request/reply messages are used by the controller 16 to ensure message dependencies have been met or to receive notifications for completed operations.
Asynchronous messages are initiated by the switch 10 and used to update the controller 16 of network events and changes to the switch 10 state. Switches 10 send asynchronous messages to the controller 16 to denote a packet arrival, switch 10 state change, or error. Asynchronous messages include Packet-in messages, Flow-Removed messages, Port-status messages, and Error messages.
A Packet-in message is sent from the switch 10 the controller 16 for every packet that does not have a matching flow entry 18 (or if a packet matches an entry 18 with a “send to controller” action 22). If the switch 10 has sufficient memory to buffer packets that are sent to the controller 16, the packet-in events contain some fraction of the packet header and a buffer ID to be used by the controller 16 when it is ready for the switch 10 to forward the packet. Switches 10 that do not support internal buffering (or have run out of internal buffering) must send the full packet to the controller 16 as part of the event.
Flow-Removed messages inform the controller 16 that the switch 18 has removed a flow entry 18 from the flow table 12. When a flow entry 18 is added to the switch 10 by a flow modify message, an idle timeout value indicates when the entry 18 should be removed due to a lack of activity. Additionally, a hard timeout value indicates when the entry 18 should be removed, regardless of activity. The flow modify message also specifies whether the switch 10 should send a flow removed message to the controller 16 when the flow expires. Flow modify messages which delete flows may also cause flow removed messages.
The switch 10 is expected to send Port-Status messages to the controller 16 as port configuration state changes. These events include change in port status (for example, if it was brought down directly by a user) or a change in port status.
Error messages are used by the switch 10 to notify the controller 16 of problems.
Symmetric messages are initiated by either the switch 10 or the controller 16 and are sent without solicitation. Symmetric messages include Hello messages, Echo messages, and Vendor messages.
Hello messages are exchanged between the switch 10 and controller 16 upon connection start-up.
Echo request/reply messages can be sent from either the switch 10 or the controller 16, and must return an echo reply. They can be used to indicate the latency, bandwidth, and/or liveness of a controller-switch connection.
Vendor messages provide a standard way for OpenFlow switches 10 to offer additional functionality within the Open Flow message space.
Protection switching is a general term referring to functionality for detecting a forwarding path/link failure in a transport network and automatically switching from the failed path/link to an operational link. Protection switching involves two mechanisms: a first mechanism for detecting that a failure has occurred in the packet forwarding path, and a second mechanism for redirecting traffic affected by the error onto a working forwarding path.
The error detection mechanism typically involves transmitting error-detection packets between network elements, either over a single link or over a multi-hop path. If the receiving node fails to receive a certain number of consecutive error-detection packets, then the forwarding between the network elements is considered broken. The error detection time resolution, i.e., how fast an error is detected, depends on the frequency of error-detection packet transmission and the number of packets that failed to be forwarded. The transmission frequency is typically an order of magnitude higher than the desired detection time, in order to provide a margin wherein a few packets may be lost without the failure detection mechanism triggering a false positive. So, for example, if the desired error detection time is 1 second, the transmission frequency may be 10 Hz.
The traffic redirection mechanism is triggered by the error detection mechanism upon forwarding failure and is responsible for quickly redirecting the traffic affected by the failure onto a working path. This may involve calculating a new path, or switching to a preconfigured path. Typically, in high-performance transport networks, the requirement is a maximum 50 milliseconds for detecting a failure and switching to a working path.
Within the current OpenFlow Switch specification, both of the mechanisms required to perform protection switching (i.e., failure detection and traffic redirection) must be implemented in the controller 16. Using the Send-Packet and Packet-In functions defined in the OpenFlow protocol, the controller 16 can instruct a switch 10 to transmit a packet on a particular forwarding path, and can receive a packet from a switch 10. If a failure is detected, the controller 16 can then update the flow table entries 18 to perform the traffic redirection. However, this solution has three major disadvantages.
First, there is a high latency in the protection switching, since information from the switch 10 must reach the controller 16 over the secure channel 14. The traffic redirection latency, i.e., the time between failure detection and actual traffic redirection, is high and variable (jitter) since the controller 16 must perform the reconfiguration of the forwarding path using the secure channel 14.
Second, the existing solution places a high load on the controller 16, since it has to transmit and receive the failure detection packets, which must be transmitted at a relatively high frequency for an acceptable failure detection time. Also, the load on the controller increases roughly linearly with each monitored path, which makes the solution difficult to scale.
Third, there is a high risk of false positives in the error detection. Since the controller 16 is transmitting and receiving the failure detection packets using the secure channel 14, not only is the path between two switches 10 monitored (which is the intention) but also the secure channel 14 itself. The secure channel 14 may be transported over an arbitrary number of hops, so it its very likely that the failure detection mechanism would trigger on changes in the secure channel 14 forwarding, thus falsely triggering traffic redirection.